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METHOD AND APPARATUS FOR IMPROVED CALL SETUP IN A 

MULTIMEDIA PACKET NETWORK 



DESCRIPTION 



10 Technical Field 



This invention is related to multimedia packet networks. Specifically, 
this invention relates to a mechanism to allow such a packet network to 
more effectively carry telephony messages, and to more efficiently interface 
with the public switched telephone network (PSTN). 



Background Art 

Evolution of the PSTN has accelerated in recent years; however, 
most of the PSTN still operates on circuit switched, time division multiplexed 
(TDM) connections. Integrated services digital network (ISDN) bearer 

20 channels often provide transport. In parallel with the PSTN, a packet based 
data network has evolved. This data network has largely been used for 
Internet traffic and data networking. Although these networks have been 
mostly separate until recently, the two networks are starting to merge. The 
merger of these networks requires that voice traffic be canried over packet 

25 networks, and further that such packet networks be able to seamlessly 
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5 integrate with traditional circuit switched networks, as the two types of 
networks may carry different call legs of the same call. 

FIG. 1 illustrates a typical TDM, PSTN call. Caller 101 places a call 
to callee 105. The call goes through end office A, 102. over some type of 
trunk bearer channel to toll office 103, then to end office B, 105, and finally 

10 to the callee. Such calls may pass through multiple toll offices, or may be 
connected directly from one end office to another. In any case, a path of 
circuits for the call is maintained throughout the call. Signaling between 
offices is typically provided by an ISUP (ISDN user part) connection. ISUP 
signaling is well understood and is standard in the telecommunications 

15 industry. For more information on ISUP signaling, see the various Interna- 
tional Telecommunications Union (ITU) Recommendations pertaining to 
telephone signaling, including Q.761, Q.764 and Q.931, the most recent 
versions of which at the time of filing this application are Incorporated herein 
by reference. 

20 FIG. 2 illustrates a call which is similar to the TDM call of FIG. 1; 

however, in this case, the call is transported from one end office to another 
(called switch offices, 202 and 204, in this case) via a packet switched 
network 203. This fact is, in theory, transparent to caller 201 and callee 205. 
ISUP+ or SIP+ provides signaling in this case. ISUP+ is essentially the 

25 same as ISUP except that ISUP+ signals contain extra fields for packet or 
cell based network information. An International Telecommunications Union 
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5 (ITU) recommendation was proposed for ISUP+ as of the filing date of this 
application as ITU Q.BICC. SIP stands for "session initiation protocol" and is 
a well-known standard. SIP and SIP+ are described in document RFC 
2543. published by the Internet Engineering Task Force (IETF), March, 1999 
which is incorporated herein by reference. SIP and SIP+ provide the same 
10 type of signaling for control of calls, but are more oriented towards packet 
based networks. 

The network of FIG. 2 has been conceptualized for some time, and 
standards groups and conference groups have written extensively about 
how to make such a network work in everyday use. In order for the call leg 

15 which is handled by the packet network to seamlessly connect with the call 
legs handled by TDM switching offices, media provided by one type of 
network must be converted into media provided by the other. This conver- 
sion is referred to as circuit emulation services (CES) in an ATM network. 
The device that provides this conversion is called a media gateway (MG). In 

20 the network of FIG. 2, a media gateway handles each end of the bearer 
connection through packet network 203. The media gateway terminates 
bearer media streams from both the switched circuit TDM network, and the 
packet network. The media gateway and the network it serves may be 
capable of processing audio and video (hence the term "multimedia packet 

25 network"). The media gateway is capable of full duplex media translations. 
It may also provide other features such as conferencing. 
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5 Each media gateway is associated with a media gateway controller 

(MGC). The media gateway is "dumb" in that it does not have call process- 
ing capabilities. The call processing capabilities for the network reside in the 
MGC. An MGC provides the signaling for call control and controls the call 
state of a media gateway. The protocol used by the MGC to control the MG 

10 is called the media gateway control protocol (or the "Megaco" protocol). 
Megaco is an application layer protocol which is also described in ITU 
Recommendation H.248, which shares a common text with the IETF Internet 
Draft "Megaco Protocol," and which is incorporated herein by reference. 
The "Megaco Protocol" Internet Draft first became an IETF working docu- 

15 ment in March, 1999. Within the Megaco protocol, session description 
protocol (SDP) can be used to describe bearer channel terminations, which 
are being controlled by the MGC's. SDP is described in document RFC 
2327, published by the IETF, April. 1998, which is incorporated herein by 
reference. Throughout the rest of this disclosure we . will refer to Megaco as 

20 "Megaco/H.248." 

Despite the fact that the theoretical workings of a network like that 
shown in FIG. 2 have been widely explored, such networks have seen 
relatively little everyday use. The reason is that there are still problems to 
be overcome before such networks exhibit the same very high quality of 

25 service for voice traffic that users of the PSTN have come to expect. Once 
such problem stems from the fact that there is no dedicated physical path for 
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5 a call through a packet network, and therefore a wait state must be provided 
so that each node in the network waits for an entire bearer path to be estab- 
lished before timing out. 

A packet switched network, used for transport of audio and video 
media streams, is typically based on asynchronous transfer mode (ATM) 

10 frame relay (FR), and Internet protocol (IP) technologies. Public ATM 
networks generally operate according to the user network interface (UNI). 
The UNI is described in the book, "ATM User Network Interface (UNI) 
Specification Version 3.1" by the ATM Forum, published by Prentice Hall 
PTR. June. 1995, which is incorporated herein by reference. An update to 

15 the UNI version 3.1. "ATM User-Network Interface (UNI) Signaling Specifi- 
cation 4.0" was published by the ATM Forum in July, 1996. and is incorpo- 
rated herein by reference. For private ATM networks, the private network to 
network interface (PNNI) describes the ATM interface. PNNI is covered in 
the ATM forum document "PNNI addendum for the network call correlation 

20 identifier" published by the ATM fomm in July 1999. which is incorporated 
herein by reference. 

In ATM. fixed-length cell carry packetized data. Each cell that is sent 
through the network has a virtual channel identifier, and other addressing 
information; however, each node in the network handles many cells that are 

25 associated with different media streams. Therefore, there is no provision for 
a node to control cells for a call throughout a call path. Media gateways and 
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5 other nodes in the path must actively wait for call setup throughout the 
network, consuming processing power and making it difficult to maintain an 
appropriate level of quality of service. What is needed is a way to more 
directly monitor the status of a connection, so that valuable processing 
power is not used to process wait states. 

10 

Disclosure of Invention 
The present invention solves the above described problem by pro- 
viding new signals and events to be used in call setup of a connection 
oriented bearer path so that no wait state is required during the path setup. 

15 These signals and events allow processors in the network to switch to other 
tasks instead of actively waiting for connections to be completed. The 
signals and events also provide for simpler and more efficient network 
implementation. The invention can be used exclusively to control call setup. 
Or it can be used in combination with transaction pending messages. 

20 A media gateway and its MGC at either or both ends of a bearer path 

can make use of the invention. In describing the invention, we use "originat- 
ing" and "terminating" to refer to the calling and called ends of the call path, 
respectively. We use the terms "near-end" and 'tar-end" to refer to the end 
of the path relative to where the particular process being discussed is taking 

25 place, usually relative to where key messages are being exchanged by a 
media gateway and an MGC. The terms "near-end" and "far-end" are used 
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5 independently of the terms "originating" and "terminating." In connection 
with call setup, the terms "fonA^ard" and "backward" refer to which end 
initiates the bearer connection through the packet network. "Forward" refers 
to a process where the originating end sets up the connection, and "back- 
ward" refers to a process where the terminating end sets up the connection. 

10 In the Megaco/H.248 protocol, a signal is a request from the MGC to 

the media gateway to apply some process to network terminations. In the 
case of TDM terminations, the signals can be in-band signals, such as 
tones, or out-of-band signals such as those specified by ISUP, In any case, 
these signals are relayed from the media gateway to the MGC where they 

15 are processed. In the case of ATM terminations, most signals are UNI 
signals or messages. An event is a notification sent from the media gate- 
way to the MGC when a requested state is reached. In the preferred em- 
bodiment, the invention is implemented with new events and signals to be 
used in the Megaco/H.248 protocol. However, the fundamental operation of 

20 these events and signals is independent of the underlying bearer network. 
The signals and events can be mapped to any underlying network such as 
ATM or frame relay. 

According to the invention, a media gateway receives a command 
from its MGC to add a connection for the bearer path and the command 

25 specifies a connection available signal for notifying the MGC if and when the 
connection is available. We abbreviate "connection available" as "coav." 
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5 Coav is both a signal and an event. When an ATM network is used for 
transport, the command from the MGC triggers the media gateway to send 
an ATM UNI setup message to the far-end media gateway. The media 
gateway then initializes the connection with the far-end media gateway. If 
there is no connection at all for the call, this initialization step involves setup 

10 and connect messages being exchanged. In most cases an "add" command 
is used to direct a media gateway to establish a bearer path, however, some 
other command, for example, a "move" command can be used. Also, as will 
be explained in more detail later, there could be a connection which has 
already been established by the far-end media gateway, in which case, the 

15 initialization step simply involves identifying the connection and correlating it 
with the current call. Once the bearer path has been established, the coav 
event is sent to the MGC. 

If the connection cannot be established, a "connection not available" 
or "cont" signal is specified. Like coav, cont is both a signal and an event. 

20 The MGC can also send cont to the media gateway to disconnect or release 
the path. The media gateway in this case can respond with the connection 
not available event. The media gateway will notify the MGC when the 
connection is disconnected at any time during the call, even if the discon- 
nection occurs because of a network failure. In this case, a notice of failure 

25 event may also be sent from the media gateway to the MGC. 
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5 As part of the process described above, an optional continuity check 

can be performed across the bearer path. This check involves one of the 
media gateways sending a continuity check message to the other media 
gateway. The media gateway receiving the continuity check then responds 
with a continuity response. In this way, a bearer path can be confirmed at 
10 the end of the setup process to ensure the reliability of the call being han- 
dled. 

The invention is implemented by software in combination with the 
hardware of the media gateway and media gateway controller. The software 
which implements many aspects of the present invention can be stored on a 

15 media. The media can be magnetic such as diskette, tape or fixed disk, or 
optical such as a CD-ROM. Additionally, the software can be supplied via a 
network. A media gateway is essentially a switching system containing 
switching fabrics, a computing module, network interfaces, and other re- 
sources. The network interfaces are implemented by adapters which are 

20 connected to switching fabrics to allow access to the system from the net- 
works. Input/output modules or adapters allow software to be loaded and 
various maintenance functions to be performed. A computing module 
contains a processor and memory that execute the software and provide the 
means to control the operation of the media gateway to implement the 

25 invention. 
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5 The media gateway controller can also be a switching systenn, but 

would more typically be a type of workstation containing a bus such a 
personal computer interconnect (PCI) bus. A workstation that typically 
implements the invention includes a plurality of input/output devices and 
adapters for connection to the necessary networks. A system unit includes 

10 both hardware (a central processing unit and memory) and software which 
together provide the means to implement the media gateway controller. 

The invention operates in a network in which media gateways act as 
endpoints to a call leg being carried on a bearer channel through the net- 
work. Each media gateway is controlled by and connected to a media 

15 gateway controller. An MGC uses the previously mentioned Megaco/H.248 
protocol to control its media gateway, and the invention provides an exten- 
sion to the Megaco/H.248 protocol. 

Brief Description of Drawings 

20 FIG. 1 conceptually illustrates a prior-art telephone connection 

through the public switched telephone network. 

FIG. 2 conceptually illustrates a telephone connection similar to that 
of FIG. 1 , except that one call leg goes through a packet switched network. 
FIG. 3 is a block diagram of one network in which the present inven- 
25 tion is used. 
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5 FIG. 4 is a block diagram of a different network in which the present 

invention is used. 

FIG. 5 is a flowchart illustrating the method of the present invention. 
FIG. 6 is a flowchart illustrating the method of the present invention in 
which a transaction pending message is used. 
10 FIG. 7 is an example message flow diagram that illustrates an exam- 

ple of how the present invention is used. 

FIG. 8 is another. example message flow diagram that illustrates an 
example of how the present invention is used.. 

FIG. 9 is another example message flow diagram that illustrates how 
15 the present invention is used. 

FIG. 10 is another example message flow diagram that illustrates the 
use of the present invention. 

FIG. 1 1 is another example message flow diagram that illustrates the 
use of the present invention. 
20 FIG. 12 is another example message flow diagram that illustrates the 

use of the present invention. 

FiG. 13 is a block diagram of a media gateway that implements the 
present invention. 

FIG. 14 is drawing of one implementation of a media gateway con- 
25 troller that is used with the present invention. 
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5 FIG. 15 shows an example of a media which stores software that 

implements the present invention. 

Modefs) for Carrying Out the Invention 
FIG. 3 illustrates one architecture in vyhich the present invention can 

10 be used. According to FIG, 3. telephone 304 is where a call originates. 
Telephone 303 is where a call terminates. Telephones 303 and 304 are 
shown as illustrations only. In reality, they can be directly connected to the 
media gateways or can be connected through extensive TDM networks. In 
the latter case, lines going into the media gateways would actually be TDM 

15 tmnks. Media gateway A, 310, is the originating media gateway and media 
gateway B, 309 is the terminating media gateway. The media gateways of 
FIG. 3 convert voice to ATM. We therefore refer to this network architecture 
as voice and telephony over ATM, or "VTOA" architecture, however, the 
same architecture can be used for Internet protocol (IP) telephony. Media 

20 gateway controller A, 301, controls media gateway A. Media gateway 
controller B, 302, controls media gateway B. Alternatively both media 
gateways can be controlled by a single MGC. Media gateway A includes 
TDM endpoint 305 and packet endpoint 306. Media gateway B includes 
TDM endpoint 308 and packet endpoint 307. Packet network 31 1 serves as 

25 the transport network through which bearer channels are established to 
interconnect calls between the two media gateways. This network and the 
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5 endpoints to which it is connected can be frame relay, ATM, IP, or some 
other type of packet network. For illustrative purposes, most of the discus- 
sion refers to an ATM network. The media gateway controllers communi- 
cate with each other via ISUP+, SIP, or SIP+. It is also possible to use a 
nonstandard protocol, specific to the manufacturer of the media gateway 

10 controllers and media gateways. 

Either a media gateway or a media gateway controller can generate 
the end-to-end call identifier (EECID), as determined by the network de- 
signer. The EECID is used to identify a call leg uniquely across the ATM 
network, regardless of the number of nodes used in completing the network 

15 path. The EECID allows the MGC's, the media gateways, and any nodes in 
the bearer path to identify the call uniquely. Note that media gateway 
controller A, 301, controls media gateway A, 310, using the Megaco/H.248 
protocol, an application layer protocol for media gateway control. Likewise, 
media gateway controller B, 302, controls media gateway B, 309, using the 

20 same Megaco/H.248 protocol. The media gateway or media gateway 
controller at either end can generate the EECID, regardless of which end is 
the originating end for the call and which end is the terminating end for the 
call. 

FIG. 4 illustrates a slightly different architecture in which the invention 
25 is used. According to FIG. 4, media gateway controller A, 401. controls 
media gateway A, 415, using the Megaco/H.248 protocol and media gate- 
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5 way controller B, 402, controls media gateway B, 414, using the 
Megaco/H.248 protocol, in FIG. 4. 403 is the originating telephone and 404 
is the terminating telephone. ATM network 411 serves as the transport 
network. Again, any of the media gateway controllers or media gateways 
can generate an EECID to identify calls being handled by the network. The 

10 main difference between the network of FIG. 4 and the network of FIG. 3 is 
that the network of FIG. 4 supports digital subscriber loop, or DSL. DSL 
comes in various types such as aDSL, sDSL and hOSL, and so "xDSL" is 
used to designate DSL in FIG. 4. In this case each media gateway includes 
a splitter; 405 in the case of media gateway 415 and 410 in the case of 

15 media gateway 414. TDM temiinations 406 and 408 and ATM endpoints 
407 and 409 each reside in their respective media gateways and allow both 
data and TDM voice to be transported across the ATM network 411. The 
splitters 405 and 410 split the voice from the data. The data connection 
from user terminal 412 is completed through splitter 405 to ATM termination 

20 407 in the case of media gateway A. The data connection from user termi- 
nal 413 is completed through splitter 410 to ATM termination 409 in the case 
of media gateway B. OthenA/ise, the operation of the network in FIG. 4 is 
essentially the same as the operation of the network of FIG. 3. 

Many aspects of the invention are implemented through enhance- 

25 ments to the previously mentioned Megaco/H.248 protocol. The connection 
model for the protocol describes logical entities, or objects, within the media 
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5 gateway that can be controlled by the media gateway controller. The model 
relies on extractions, primarily terminations and contexts. A termination 
sources and/or sinks one or more media streams. A context is an associa- 
tion between a collection of terminations. 

In general, an "add" command is used to add terminations to con- 

10 texts. A termination may be moved from one context to another with a 
"move" command. A termination exists in, at most, one context at a time. A 
non-packet termination can exist outside of a context. Property values can 
be set for terminations by including appropriate descriptors as parameters to 
the various commands in the Megaco/H.248 protocol. A termination in a 

15 context may have its value changed by the "modify" command. Other 
commands that are important to the implementation of the invention will be 
discussed later. 

As previously mentioned, according to one aspect of the invention an 
end-to-end call identifier (EECID) is associated with a call, and with a bearer 

20 path through the packet network, which completes a call leg. When we say 
the EECID is associated with a call or a path, we mean that all of the nodes 
and devices involved in maintaining a call leg are aware of which call to 
which specific Directory Numbers (DN's), or other user address are associ- 
ated with each packet of information which flows through the relevant part of 

25 the network. Depending on the type of underlying networks and/or protocols 
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5 the EECID can be carried across the network in various ways. Details of 
some possible signaling will be discussed later. 

It is preferable to include the EECID in the Megaco/H.248 protocol as 
part of the stream descriptor in addition to the local control descriptor, local 
descriptor, and remote descriptor. These descriptors are all part of the 

10 stream parameter, a known part of the Megaco/H.248 protocol. It is also 
possible to include the EECID in the Megaco/H.248 protocol as part of a 
session descriptor protocol (SDP) term. SDP is a well-known protocol, 
described in the previously cited IETF RFC 2327. which is used to describe 
packet terminations, such as IP and ATM terminations within the 

1 5 Megaco/H.248 protocol. 

In addition to including the EECID in the Megaco/H.248 protocol, it 
must be included in other protocols and/or data streams that allow the 
network to communicate. It is especially important to include the EECID In 
the ATM cell structure used in the ATM transport network, since the media 

20 gateways on the ends of the ATM networks form the ends of the bearer 
channel carrying the part of the call leg which passes through the packet 
network. Assuming the packet networi< shown in FIG. 3 and FIG. 4 is an 
ATM network implemented according to the UNI standard promulgated by 
the ATM fomm, there is a choice of possible places in an ATM cell where 

25 the EECID can be placed. The network prefix is a fixed, required part of the 
cell, used for routing. The EECID could be placed in the ATM user part. 
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5 ATM network routing only uses the first thirteen-byte network preifix of the 
ATM address. The following 7 bytes of the user part can be used to trans- 
port the EECID. Another possible place for the EECID is the ATM subad- 
dressing. The subaddressing field usually only has local significance and 
can be dropped if it is unused. It can be adapted to implement the EECID of 

10 the present invention. Most non-UNI 4.0 compliant ATM networks are 
currently implemented without using a generic information trans- 
port/information element (GIT IE) field; however, the GIT IE field will proba- 
bly be the best place for the EECID as that field becomes more widely used. 
The EECID must also be included in ISUP+ messages, if ISUP+ is 

15 used between the two gateway media controllers. FIG. 8 shows an ISUP+ 
message. Field 801 contains the ISUP information and 802 contains the 
ISUP+ information, which is essentially directed towards packet based 
networks, and includes an application transport mechanism field. The 
EECID is preferably included in the transport mechanism field. 

20 If SIP+ is used between the two media gateway controllers, the 

EECID is carried as a term in the session description protocol (SDP). 
Syntax for the session description protocol, which includes the EECID, is 
"c=eecid: (eecid value)" or "a=eecid: (eecid value)." Note that the terms 
"c=eecid: (eecid value)" or "a=eecid: (eecid value)" need not be used if the 

25 stream descriptor is used to specify the EECID in the Megaco/H.248 proto- 
col. 
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5 As previously discussed, either an MGC or a media gateway some- 

where in the network selects the EECID, that is. determines a value for the 
EECID. before it can be associated with a call leg. The EECID can be any 
arbitrary number that is unique so as to allow correlation of the end-to-end 
network path between the two media gateways. The choice of the value for 

10 the EECID has implications for the call flow. In some cases, the value can 
only be derived by the network, as with the NCCI as discussed above. 
Preferably, the value of the EECID is not dependent on the underlying 
network architecture. A simple way to create an EECID is to simply have 
the device that is detemnining the EECID. generate a random number. It is 

15 also possible to use a number that is already associated with some part of 
the network. 

A possible value to use for the EECID is a session-ID or calUD. The 
session-ID is a random number passed from the MGC to the media gate- 
way. The media gateway can then pass the session-ID to the far end media 

20 gateway as an EECID with its initial setup message. The session-ID can 
also be passed through ISUP+ messages. The session-ID would not be 
able to be used if the media. gateway is to generate the EECID. The call-ID 
is similar to the session-ID. Both are specified to identify a call solely within 
an MGC or media gateway. 

25 . Finally, the most preferable value for the EECID, assuming a numeri- 

cal value, which is associated with the network, is used, is the ATM sup- 
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5 ported backward network connection identifier (BNC-ID). The BNC-ID is 
four bytes long and is generated by the nnedia gateway. The media gateway 
sends the BNC-ID to Its media gateway controller for forwarding to the far- 
end. The BNC-ID is included in the setup command between media gate- 
ways to correlate the call. 

10 According to our invention, a package with a signal, called a "connec- 

tion available" (coav) signal, that explicitly requests the establishment of the 
packet network path, an event, called a "connection available" (coav) event, 
that explicitly reports the successful completion of the path, and an event, 
called "connection not available" (cont), that explicitly reports the failure to 

15 establish the requested path can be added to any protocol that is used for 
call control in any packet-based network. Similarly, the package would 
include a signal, called a "connection not available" (cont) signal, that explic- 
itly requests the release of the packet network path, and an event, called a 
"connection not available" (cont) event, that explicitly reports the successful 

20 release of the path. If the invention is used with the Megaco/H.248 protocol, 
these signals and events can be used alone, or with an existing provisional 
response mechanism implemented through the 'transaction pending" com- 
mand. The events and signals that are used with Megaco/H.248 in both of 
these alternatives are shown in the following table. The signals and events 

25 symbolized by the "coav" and the "cont" symbols are new according to the 
invention. The EECID, previously discussed, is an optional parameter for 
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5 the coav and cont events, hence it is denoted with the letter O. If a media 
gateway fails to release a packet network path, the media gateway sends a 
"report failure" (of) event to the media gateway controller. The continuity 
check, continuity response, and report failure are also part of this package, 
which we call the "packet pipe" event package: 

10 



Symbol Definition 


R 


S 


Parameter(s) 


coav bearer connection available 


X 


BR 


EECID (0) 


cont bearer connection not available 


X 


BR 


EECID (O) 


co1 continuity check 


X 


TO 




co2 continuity response 


X 


TO 


Duration 


of report failure 


X 




Duration 



R specifies that each symbol is part of an event report. BR indicates a brief 
20 tone. TO indicates a timeout tone that stops after the amount of time speci- 
fied by the duration parameter has passed. Note that the co1 and co2 
signal/events are shown for illustrative purposes only to demonstrate the 
optional use of continuity testing in conjunction with the process of setting up 
a bearer path. These signals are not required to implement the present 
25 invention in Megaco/H.248. 

The explicit request alternative has desirable characteristics. In par- 
ticular, the use of explicit signals and events eliminates the need for the 
media gateway to maintain the state of an add transaction request. The 
explicit embodiment also reduces the transaction request state monitoring in 
30 the MGC. and eliminates the need for the media gateway to potentially send 
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5 multiple transaction pending replies. The explicit signals and events also 
reduce complexity when multiple add commands are used in a single trans- 
action. 

When requesting establishment of a network path, an add command 
is sent to the media gateway, which then explicitly specifies the "connection 

10 available" (coav) signal and event. When requesting release of a network 
path, a subtract command is sent to the media gateway, which then explic- 
itly specifies the "connection not available" (cont) signal and event. The 
coav signal is sent only to the ATM termination, which is responsible for the 
origination of the setup sequence of the network path. The transaction. 

15 which specifies these requests, is acknowledged on receipt. The media 
gateway manifests the coav signal for an ATM network. A notify message of 
the coav or the "of event is sent from the media gateway to the MGC upon 
a connection becoming available or upon failure to establish the connection, 
respectively. Note that the use of the coav and cont signals are optional. If 

20 they are not used, the initiation of the establishment or release of the path is 
implied by the add or subtract command, respectively. 

The continuity check and response can be used automatically by the 
media gateway without an instruction from the MGC. However, these two 
events/signals can also be requested by the MGC during call processing. 

25 An additional characteristic of this approach is that embedded signals and 



21 



wo 01/15486 PCTAJSOO/22853 

5 events can be used to allow for additional processing to be invoked auto- 
matically for such things as continuity checking of the network path. 

An alternative way of making a connection request is based on the 
Megaco/H.248 provisional response "transaction pending" reply wait state. 
This command is used when a command is received but pending for com- 

10 pletion of processing. The media gateway can respond to the MGC with a 
command "transaction pending" response, so that the MGC won't be 
blocked for the completion response. When the media gateway finishes 
executing the command, it can then send the "transaction reply" message to 
acknowledge that the original command has been successfully completed or 

15 has failed. In addition to using the coav signal explicitly, the connection 
request is expressed implicitly by the add command. The rationale behind 
this approach is that the packet connection does not exist until it is added to 
the context. Therefore, the add command implies setting up the bearer 
connection. 

20 The EECID is present in either the stream descriptor or the termina- 

tion descriptor for the network path. The media gateway must use the 
EECID to determine if it needs to initiate the network path setup. The media 
gateway will keep a record of all requests received from other media gate- 
ways for setup of a network path. When the add command is received, the 

25 media gateway will determine if a bearer path setup request with the speci- 
fied EECID has been received. If a network path associated with the EECID 
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5 exists, then the network path bearer connection already exists and the 
correlation is reported back to the MGC via a transaction reply. If.no pend- 
ing network path is found with the same EECID, then the path initialization is 
invoked. In this approach, there won't be a coav signal and bearer connec- 
tion available event notification. If the media gateway determines that there 

10 will be sufficient delay setting up the bearer connection to cause the trans- 
action request to time out, the media gateway will respond to the media 
gateway controller with a transaction pending response. Upon completing 
the bearer connection, the media gateway will respond to the MGC with a 
transaction reply indicating success or failure of the attempt. 

15 The method described immediately above can incur processing over- 

head in determining whether or not network path setup is required. Another 
negative consideration is that there is no mechanism to use embedded 
signals and events to allow for automatic processing of subsequent actions 
such as continuity checking of the network bearer path. The MGC has to 

20 issue a separate message for continuity checking and response. This 
combination at least eliminates the need for the media gateway to search 
through pending network path requests to determine if a network path setup 
is required. If the coav signal is present, the setup will begin immediately. If 
the two embodiments are used simultaneously, accommodations have to be 

25 made to eliminate redundant messaging to report the completion of the add 
command and the coav or cont event. 
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5 Figures 5 and 6 illustrate the overall method of the invention. FIG. 5 

is a flowchart that shows the explicit call setup method. At 501 the add 
command is sent from the MGC to the media gateway. The add command 
can specify any signal and response that the media gateway will under- 
stand. In this case, the signal and response is coav for connection avail- 
10 able, and/or cont for connection not available. At 502 the add command is 
confirmed. In this embodiment, the confirmation takes the form of an imme- 
diate transaction reply message to the MGC. At 503 the bearer connection 
is initialized. 

The bearer connection can be initialized either by the media gateway 
15 setting up the bearer connection, called a fonA^ard setup, or the media 
gateway simply identifying an existing bearer connection, which has been 
set up by a far-end media gateway, called a backward setup. In either case, 
the media gateway waits until the bearer path is completely established at 
504, and responds with a coav event at 505. The MGC will typically notify 
20 the far-end MGC of this occurrence at 506. An optional continuity check is 
shown as being performed at 507. This continuity check consists of a 
continuity check message being sent to the far-end media gateway, and a 
response being received. If the connection is not available in FIG. 5, a cont 
event is sent to the MGC at 508, and the far end is notified at 509. The 
25 process then ends at 51 0. 
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5 The flowchart of FIG. 6 illustrates the implicit call setup method used 

with the new signals and events of the invention. At 601 an add command 
is given by the MGC to the media gateway as before. This time, however, 
the media gateway responds with a transaction pending message at 602, 
which forces the MGC to wait until it receives further instructions from the 

10 media gateway. At 603, the media gateway again initializes the bearer path. 
Only after the bearer path is fully established is the transaction reply sent to 
the MGC at 608. A coav event is returned to the MGC at 609. The far-end 
is notified at 610. Again, a continuity check is optionally performed at 61 1, 
In FIG. 6, if the bearer path has not been established at 604 after a 

15 time-out at 605, the cont event is returned to the MGC at 606. The far end 
is notified at 607. In this case, a continuity check can still be perfonned at 
61 1 to further check the status of the network. 

To illustrate the detail of the invention, Figures 7-12 present detailed 
signal flows showing the setup of bearer path connections in a multimedia 

20 packet network. There are literally dozens of possible signal flows, which 
could be implemented to make use of the invention. The signal flows pre- 
sented here should be considered as examples only. When we refer to 
implicit versus explicit setup, we are using the terminology discussed above 
for explicit versus implicit signaling and events. When we refer to fon/vard 

25 setup versus backward setup we are referring to which end of the network is 
performing the bearer path setup relative to the originating end of the net- 
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5 work. If the originating end of the network is also setting up the bearer 
connection we have a forward setup. If the originating end of the network is 
passing information to the terminating end and the terminating end is setting 
up the bearer connection, we have a backward setup. In reference to FIG. 
9, all messages are discussed. For the other message flow diagrams, only 

10 new messages, which are important to Illustrating the differences between 
those examples and previous examples, are discussed. The letters A and B 
correspond to the ends of the network path as shown in the network dia- 
grams of Figures 3 and 4. 

In Figures 7-12, the TDM termination is a logical representation of a 

15 TDM line and an ATM tennination is a logical representation of an ATM 
network connection. Although an ATM termination is illustrated in all cases, 
the invention is not limited to use of an ATM network for the bearer connec- 
tion. The invention is also applicable with other connection-oriented net- 
works such as frame relay networks. 

20 Turning to FIG. 7, an explicit fonA^ard setup is illustrated. At 710, a 

notify message indicating an offhook condition is sent from media gateway A 
to MGC A. At 71 1, MGC A responds with an add command. At 716, media 
gateway A replies with a transaction reply. At 713 and 701, the two media 
gateway controllers negotiate connection parameters. At 714, MGC A 

25 sends a pipe connect request to MGC B. In this case, at 702, MGC B sends 
an add command to media gateway B with explicit instructions for setting up 
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5 the bearer path with the connection signal coav and the event coav when 
the connection is available. At 703, nnedia gateway B immediately responds 
to MGC B with a transaction reply signal; the transaction reply signal Is in 
response to an add command. This transaction reply does not mean that 
the add command is completed. Rather, the transaction reply simply means 

10 that media gateway B is working on adding the ATM termination. Media 
gateway B chooses an EECID at 702 and sends the EECID back to MGC B 
at 703. MGC B passes the EECID to MGC A at 707. At 715. MGC A sends 
the add command with the EECID and explicit event and signal coav. Media 
gateway A immediately replies to MGC A with a transaction reply at 717. At 

15 704, the UNI setup message is sent from media gateway A through the ATM 
network to media gateway B. A connect message is sent from media gate- 
way B to media gateway A to indicate the bearer path is accepted at 705. 
Media gateway B uses the EECID to associate the call and the bearer path. 
This prevents an unauthorized bearer connection from being set up. Then 

20 MGC B notifies media gateway B at 706. 

After receiving a UNI connect message from media gateway B. media 
gateway A notifies MGC A that the coav event has occurred at 708. In the 
above example, the MGC B cannot add the ATM terminafion until the UNI 
service has been set up. This limitation comes about because the EECID is 

25 needed to create the ATM termination. At 718. MGC B is notified by MGC A 
through ISUP+ or other means that the bearer path (packet pipe) has been 
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5 established- The process is completed with the pipe connect complete ack 
message at 712. 

FIG. 8 illustrates the signal flows for explicit backward setup. At 801, 
MGC A chooses the EECID and passes it to media gateway A. There is an 
embedded continuity check applied after the coav event occurs and there is 

10 a return continuity check associated with the continuity check event. At 812, 
MGC A passes the EECID to MGC B. At 802, media gateway A sends a 
transaction reply to the add command to acknowledge that the transaction is 
accepted. Once again, the add command has not been fully executed. At 
811, MGC B sends an add command to MG B. This command asks for a 

15 bearer path to be set up using signal=coav. At 803, media gateway B sends 
the ATM UNI setup message with an EECID to media gateway A. An event 
notification on coav with embedded event co1 and signal co2 is explicitly 
requested. Upon receipt of continuity check col response co2 will be given. 
This command also asks for a bearer path to be set up using signal=coav. 

20 After the connection is set up, media gateway B responds at 805 with a coav 
event. At 809 MG A also notifies MGC A that event=coav has occurred. At 
806, the continuity check signal is applied by media gateway A since the 
coav has occurred. At 807, media gateway B applies the continuity check 
response signal since it receives the continuity check event. At 808. media 

25 gateway B notifies its media gateway controller that the continuity check 
event has occurred. Similarly, media gateway A notifies its media gateway 
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5 controller that the coav and the continuity check return events have both 
occurred at 810. 

FIG. 9 illustrates the message flows for implicit backward setup. In 
this case, the EECID is assigned by the media gateway. At 901. media 
gateway A chooses the EECID and sends a transaction pending response 

10 with the EECID to its media gateway controller so that the media gateway 
controller waits for the setup. At 902, media gateway B passes the EECID 
in the UNI setup message to media gateway A. At 903, when the connec- 
tion setup is complete, media gateway A sends a transaction reply to the 
add command and the EECID to media gateway controller A. Media gate- 

15 way B immediately sends a transaction reply to the add command to MGC 
B. 

FIG. 10 also illustrates an implicit forward setup. In this case a media 
gateway controller creates the EECID. Also, the co1 and co2 continuity 
checking messages are used. At 1001, an add command with the EECID is 

20 sent from media gateway controller A to media gateway A. At 1002, media 
gateway A responds to its MGC with a transaction pending command. Note 
that media gateway A still uses the EECID for establishing the connection 
with media gateway B. 1003 and 1004 illustrate the continuity check and 
continuity check response, respectively. 

25 Figures 11 and 12 illustrate what happens when a failure occurs. In 

FIG. 11, at 1101. MG B can't accept the UNI setup due to an error. Any 
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5 number of things could cause the en^or. One possibility is that there is no 
EECID known at MG B that matches the one in the UNI setup message. At 
1104, MG B reports failure (of) to MGC B. At 1102 MG A times out or 
receives a reject message from MG B. MG A reports failure (of) to MGC A 
at 1103. At 1105. and 1106, MGC a and MGC B exchange messages to 

10 disconnect the pipe connection. Messages like that shown at 1105 and 
1 1 06 can come from either MGC A or MGC B. 

In FIG. 12, the EECID is created and sent from MG A to MGC A at 
1201. MG A sends the UNI setup message at 1202, but it is rejected at 
1206. After the add command is confirmed at 1205. a report of failure (of) is 

15 sent from MG A to MGC A at 1208. A report of failure is also sent from MG 
Bto MGC Bat 1207. 

FIG. 13 illustrates a conceptual, functional block diagram of a switch- 
ing system, which can be used to implement a media gateway, which in tum 
implements the invention. Computing module 1301 includes a central 

20 processing unit, memory, and supporting circuitry. This computing module, 
together with any computer program code stored in the memory, is the 
means for controlling the overall operation of the switching system to per- 
form the method of the invention. TDM switching fabric 1302 is for switching 
TDM channels and is controlled by the computing module. Input/output (I/O) 

25 module 1304 is also connected to the processor of computing module 1301 
and includes media devices to load computer program code as well as 
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5 connections for workstations or other equipment for control and mainte- 
nance of the switching system. TDM network access module 1303 serves 
as a TDM network interface and is connected to TDM switching fabric 1302, 
both of which are managed by the computing module 1301. Circuit emula- 
tion system 1305 provides circuit emulation services, converting TDM voice 
10 to packets such as ATM cells. Packet switching fabric 1306 sends and 
receives packets on the packet network through packet network interface 
1307. 

FIG. 14 illustrates a workstation, which can be used to Implement a 
media gateway controller according to the present invention. I/O devices 

15 such as keyboard 1402, mouse 1403 and display 1404 are used to control 
the system. One or more of these devices may not be present in normal 
operation. System unit 1401 is connected to all devices and contains 
memory, media devices, and a central processing unit (CPU) all of which 
together form the means to implement the present invention. Network 

20 interfaces are normally implemented via adapter cards plugged into a bus, 
however, for the sake of simplicity they are shown graphically as interface 
1405. 

As previously mentioned, appropriate computer program code in 
combination with appropriate hardware implements most of the elements of 
25 the present invention. This computer program code is often stored on 
storage media. This media can be a diskette, hard disk, CD-ROM, or tape. 
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5 The media can also be a memory storage device or collection of memory 
storage devices such as read-only memory (ROM) or random access mem- 
ory (RAM). Additionally, the computer code can be transferred to the work- 
station over the Internet or some other type of network. FIG. 15 illustrates 
one example of a media. FIG. 15 shows a diskette of the type where 

10 magnetic media 1502 is enclosed in a protective jacket 1501 . Magnetic field 
changes over the surface of the magnetic media 1502 are used to encode 
the computer program code. In this way the computer program code is 
stored for later retrieval. 

We have described specific embodiments of our invention, which pro- 

15 vides an end-to-end call identifier (EECID) to uniquely identify a call leg 
across a packet network, regardless of the number of nodes used in com- 
pleting the network path. One of ordinary skill in the networking and com- 
puting arts will quickly recognize that the invention has other applications in 
other environments. In fact, many embodiments and implementations are 

20 possible. The following claims are in no way intended to limit the scope of 
the invention to the specific embodiments described. 
We claim: 
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CLAIMS 

1 1. In a media gateway, a method of establishing a bearer path 

2 through a multimedia packet network, the method comprising the steps of: 

3 receiving (501) a command from a media gateway controller 

4 (MGC) to establish a connection for the bearer path; 

5 confirming (502) the command with the MGC; 

6 initializing (503) the connection with a far-end media gateway; 

7 and 

8 sending (505) a connection available event to the MGC if and 

9 when the bearer path has been established so that call setup can be 
10 completed without processing a wait state. 

1 2. The method of claim 1 wherein the command specifies a connec- 

2 tion available signal and a request for notification of connection available 

3 and connection not available events. 



1 3. The method of claim 1 , further comprising the step of sending 

2 (508) a connection not available event to the MGC if and when a determina- 

3 tion has been made that the bearer path cannot be established. 
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1 4. The method of claim 2 further comprising the step of sending 

2 (508) a connection not available event to the MGC if and when a determina- 

3 tion has been made that the bearer path cannot be established. 



1 5. In a media gateway, a method of releasing a bearer path through 

2 a multimedia packet network, the method comprising the steps of: 

3 receiving a command from a media gateway controller (MGC) 

4 to release a connection for the bearer path; 

5 confirming the command with the MGC; 

6 releasing the connection with a far-end media gateway; and 

7 sending a connection not available event to the MGC if and 

8 when a deterniination has been made that the bearer path has been 

9 released. 



1 6. The method of claim 5 wherein the command specifies a connec- 

2 tion not available signal and a request for notification of a connection not 

3 available event. 
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1 7. In a media gateway controller (MGC), a method of directing a me- 

2 dia gateway to establish a bearer path through a multimedia packet network, 

3 the method comprising the steps of: 

4 sending (601) a command to the media gateway to establish a 

5 connection for the bearer path; 

6 confirming the command with the media gateway; and 

7 receiving (609) a connection available event from the media 

8 gateway if and when the bearer path has been established so that 

9 call setup can be completed without processing a wait state. 



1 8. The method of claim 7 wherein the command specifies a connec- 

2 tion available signal and a request for notification of connection available 

3 and connection not available events. 

1 9. The method of claim 7, further comprising the step of receiving a 

2 connection not available event from the media gateway if and when a 

3 determination has been made that the bearer path cannot be established. 
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1 10. The method of claim 8 further comprising the step of receiving a 

2 connection not available event from the media gateway if and when a 

3 determination has been made that the bearer path cannot be established. 



4 7 

1 11, In a media gateway controller (MGC), a method of directing a 

2 media gateway to release a bearer path through a multimedia packet net- 

3 work, the method comprising the steps of: 

4 sending a command to the media gateway to release a con- 

5 nection for the bearer path; 

6 confirming the command with the media gateway; and 

7 receiving a connection not available event from the media 

8 gateway if and when a determination has been made that the bearer 

9 path has been released. 

1 12. The method of claim 11 wherein the command specifies a con- 

2 nection not available signal and a request for notification of . a connection not 

3 available event. 



36 



wo 01/15486 PCTAJS00/228S3 



1 13. A computer program product (1501, 1502) for enabling a media 

2 gateway to establish a bearer path through a multimedia packet network, the 

3 computer program product having a media with a computer program em- 

4 bodied thereon, the computer program comprising: 

5 computer program code for initializing a connection for the 

6 bearer path in response to receiving a command from a media gate- 

7 way controller (MGC) to establish a connection for the bearer path; 

8 computer program code for confirming commands with the 

9 MGC; 

10 computer program code for sending a connection available 

1 1 event to the MGC if and when the bearer path has been established 

12 so that call setup can be completed without processing a wait state; 

13 and 

14 computer program code for sending a connection not available 

15 event to the MGC if and when a determination has been made that 

16 the bearer path cannot be established. 



1 14. The computer program product of claim 13 wherein the computer 

2 program further comprises computer program code for releasing the con- 

3 nection for the bearer path in response to receiving a command from the 

4 MGC to release the connection for the bearer path and confirming that the 
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5 connection has been released by sending the connection not available 

6 event. 

1 15. The computer program product of claim 13 wherein the com- 

2 mand to establish a connection specifies a connection available signal and a 

3 request for notification of the connection available and connection not 

4 available events. 

1 16. The computer program product of claim 14 wherein the com- 

2 mand to establish a connection specifies a connection available signal and a 

3 request for notification of the connection available and connection not 

4 available events and the command to release the connection specifies a 

5 connection not available signal and a request for notification of a connection 

6 not available event. 

1 17. A computer program product (1501, 1502) for enabling a media 

2 gateway controller (MGC) to direct a media gateway to establish a bearer 

3 path through a multimedia packet network, the computer program product 
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4 having a media with a computer program embodied thereon, the computer 

5 program comprising: 



6 computer program code for sending a command to the media 

7 gateway to establish a connection for the bearer path; 

8 computer program code for confirming commands with the 

9 media gateway; 

10 computer program code for receiving a connection available 

11 event from the media gateway if and when the bearer path has been 

12 established so that call setup can be completed without processing a 

13 wait state and for receiving a connection not available event if and 

14 when a determination has been made that the bearer path cannot be 

15 established. 

1 18. The computer program product of claim 17 wherein the computer 



2 program further comprises computer program code for sending a command 

3 to the media gateway to release the connection for the bearer path and for 

4 receiving the connection not available event in response. 

1 19. The computer program product of claim 17 wherein the com- 

2 mand to establish a connection specifies a connection available signal and a 
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3 request for notification of the connection available and connection not 

4 available events. 

1 20. The computer program product of claim 18 wherein the com- 

2 mand to establish a connection specifies a connection available signal and a 

3 request for notification . of the connection available and connection not 

4 available events and the command to release the connection specifies a 

5 connection not available signal and a request for notification of a connection 

6 not available event. 



1 21. Apparatus for establishing a bearer path through a multimedia 

2 packet network, the apparatus comprising: 

3 means for initializing (1301, 1304, 1306, 1307) a connection 

4 for the bearer path in response to receiving a command from a media 

5 gateway controller (MGC) to establish a connection for the bearer 

6 path; 

7 means for sending (1301, 1304) a connection available event 

8 to the MGC if and when the bearer path has been established so that 

9 call setup can be completed without processing a wait state; and 



40 



wo 01/1 5486 PCT/USOO/22853 



10 means for sending (1301, 1304) a connection not available 

1 1 event to the MGC if and when a determination has been made that 

1 2 the bearer path cannot be established. 

1 22. Apparatus for directing a media gateway to establish a bearer 

2 path through a multimedia packet network, the apparatus comprising: 

3 means for sending (1401, 1405) a command to the media 

4 gateway to establish a connection for the bearer path; 

5 means for receiving (1401, 1405) a connection available event 

6 from the media gateway if and when the bearer path has been estab- 

7 lished so that call setup can be completed without processing a wait 

8 state and for receiving a connection not available event if and when a 

9 determination has been made that the bearer path cannot be estab- 
10 lished. 

1 23. A media gateway for establishing a bearer path through a multi- 

2 media packet network under the control of a media gateway controller 

3 (MGC), the media gateway comprising: 

4 a switching fabric (1 302, 1 306); 



41 



wo 01/15486 PCT/US00y22853 



5 one or more network interfaces (1303, 1307) connected to the 

6 switching fabric; and 

7 a computing module (1301) connected to the switching fabric 

8 for controlling the switching fabric according to a computer program to 

9 enable the media gateway to receive commands from a media gate- 

10 way controller (MGC) to establish and release connections for the 

1 1 bearer path, and send a connection available event to the MGC if and 

12 when the bearer path is established and a connection not available 

13 event to the MGC if and when a bearer path is not established. 

1 24. The media gateway of claim 23 wherein a command to establish 



2 a connection specifies a connection available signal and a request for 

3 notification of the connection available and connection not available events 

4 and a command to release the connection specifies a connection not avail- 

5 able signal and a request for notification of a connection not available event. 

1 25. A programmed computer system (1401, 1405) that is operable as 

2 a media gateway controller, the programmed computer system having 

3 connections (1405) for at least one media gateway, the programmed com- 

4 puter system including a computer program comprising: 
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5 computer program code for sending a command to the media 

6 gateway to establish a connection for a bearer path; 

7 computer program code for confirming commands with the 

8 media gateway; 

g computer program code for receiving a connection available 

10 event from the media gateway if and when the bearer path has been 

1 1 established so that call setup can be completed without processing a 

12 wait state and for receiving a connection not available event if and 

13 when a determination has been made that the bearer path cannot be 

14 established. 

1 26. The computer system of claim 25 wherein the computer program 



2 further comprises computer program code for sending a command to the 

3 media gateway to release the connection for the bearer path and for receiv- 

4 Ing the connection not available event in response. 



1 27. The computer system of claim 25 wherein the command to 

2 establish a connection specifies a connection available signal and a request 

3 for notification of the connection available and connection not available 

4 events. 
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1 28. The computer system of claim 26 wherein the command to es- 

2 tablish a connection specifies a connection available signal and a request 

3 for notification of the connection available and connection not available 

4 events and the command to release the connection specifies a connection 

5 not available signal and a request for notification of a connection not avail- 

6 able event. 

1 29- A packet network for supplying bearer paths for multimedia calls 

2 comprising: 

3 at least one media gateway (309, 310, 414, 415) for initializing 

4 and releasing bearer path connections according to commands re- 

5 ceived, the media gateway also operable to send a connection avail- 

6 able event if and when the bearer path is established and a 

7 connection not available event if and when a bearer path is not es- 

8 tabiished; and 

g at least one media gateway controller (MGC) (301, 302, 401, 

10 402) connected to the media gateway, the MGC operable to send the 

1 1 commands to media gateway and to receive the connection available 

12 event and the connection not available event. 

« 
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1 30. The network claim 29 wherein the commands include a com- 

2 mand to establish a connection that specifies a connection available signal 

3 and a request for notification of the connection available and connection not 

4 available events. 

1 31 . The network of claim 30 wherein the commands further include a 

2 command to release the connection that specifies a connection not available 

3 signal and a request for notification of a connection not available event. 
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